home *** CD-ROM | disk | FTP | other *** search
-
-
- Network Working Group J. Postel
- Request for Comments: 777 ISI
- April 1981
- Updates: IENs 109, 128
- Updates: RFC 760
-
- Internet Control Message Protocol
-
-
-
- Introduction
-
- The Internet Protocol (IP) [1] is used for host-to-host datagram
- service in a system of interconnected networks called the
- Catenet [2]. The network connecting devices are called Gateways.
- These gateways communicate between themselves for control purposes
- via a Gateway to Gateway Protocol (GGP) [3,4]. Occasionally a
- gateway or destination host will communicate with a source host, for
- example, to report an error in datagram processing. For such
- purposes this protocol, the Internet Control Message Protocol (ICMP),
- is used. ICMP, uses the basic support of IP as if it were a higher
- level protocol, however, ICMP is actually an integral part of IP, and
- must be implemented by every IP module.
-
- ICMP messages are sent in several situations: for example, when a
- datagram cannot reach its destination, when the gateway does not have
- the buffering capacity to forward a datagram, and when the gateway
- can direct the host to send traffic on a shorter route.
-
- The Internet Protocol is not designed to be absolutely reliable. The
- purpose of these control messages is to provide feedback about
- problems in the communication environment, not to make IP reliable.
- There are still no guarantees that a datagram will be delivered or a
- control message will be returned. Some datagrams may still be
- undelivered without any report of their loss. The higher level
- protocols that use IP must implement their own reliability procedures
- if reliable communication is required.
-
- The ICMP messages typically report errors in the processing of
- datagrams, to avoid the infinite regress of messages about messages
- etc., no ICMP messages are sent about ICMP messages.
-
- Message Formats
-
- ICMP messages are sent using the basic IP header. The first octet of
- the data portion of the datagram is a ICMP type field; the value of
- this field determines the format of the remaining data. Any field
- labeled "unused" is reserved for later extensions and must be zero
- when sent, but receivers should not check these fields. Unless
- otherwise noted under the individual format descriptions, the values
- of the internet header fields are as follows:
-
-
-
-
- [Page 1]
-
-
- April 1981
- RFC 777
-
-
-
- Version
-
- 4
-
- IHL
-
- Internet header length in 32-bit words.
-
- Type of Service
-
- 0
-
- Total Length
-
- Length of internet header and data in octets.
-
- Identification, Flags, Fragment Offset
-
- Used in fragmentation, see [1].
-
- Time to Live
-
- Time to live in seconds; as this field is decremented at each
- machine in which the datagram is processed, the value in this
- field should be at least as great as the number of gateways which
- this datagram will traverse.
-
- Protocol
-
- ICMP = 1
-
- Header Checksum
-
- The 16 bit one's complement of the one's complement sum of all 16
- bit words in the header. For computing the checksum, the checksum
- field should be zero. This checksum may be replaced in the
- future.
-
- Source Address
-
- The address of the gateway or host that composes the ICMP message.
- Unless otherwise noted, this can be any of a gateway's addresses.
-
- Destination Address
-
- The address of the gateway or host to which the message should be
- sent.
-
-
-
-
- [Page 2]
-
-
- April 1981
- RFC 777
-
-
-
- Destination Unreachable Message
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | unused |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Internet Header + 64 bits of Original Data Datagram |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- IP Fields:
-
- Destination Address
-
- The source network and address from the original datagram's data.
-
- ICMP Fields:
-
- Type
-
- 3
-
- Code
-
- 0 = net unreachable;
-
- 1 = host unreachable;
-
- 2 = protocol unreachable;
-
- 3 = port unreachable;
-
- 4 = fragmentation needed and DF set.
-
- Internet Header + 64 bits of Data Datagram
-
- The internet header plus the first 64 bits of the original
- datagram's data. This data is used by the host to match the
- message to the appropriate process. If a higher level protocol
- uses port numbers, they are assumed to be in the first 64 data
- bits of the original datagram's data.
-
- Description
-
- If, according to the information in the gateway's routing tables,
- the network specified in the internet destination field of a
- datagram is unreachable, e.g., the distance to the network is
- infinity, the gateway sends a destination unreachable message to
-
-
-
- [Page 3]
-
-
- April 1981
- RFC 777
-
-
-
- the internet source host of the datagram. In addition, in some
- networks, the gateway may be able to determine if the internet
- destination host is unreachable. Gateways in these networks may
- send destination unreachable messages to the source host when the
- destination host is unreachable.
-
- If, in the destination host, the IP module cannot deliver the
- datagram because the indicated protocol module or process port is
- not active, the destination host may send a destination
- unreachable message to the source host.
-
- Another case is when a datagram must be fragmented to be forwarded
- by a gateway yet the Don't Fragment flag is on. In this case the
- gateway must discard the datagram and return a destination
- unreachable message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 4]
-
-
- April 1981
- RFC 777
-
-
-
- Time Exceeded Message
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | unused |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Internet Header + 64 bits of Original Data Datagram |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- IP Fields:
-
- Destination Address
-
- The source network and address from the original datagram's data.
-
- ICMP Fields:
-
- Type
-
- 11
-
- Code
-
- 0 = time to live exceeded in transit;
-
- 1 = fragment reassembly time exceeded.
-
- Internet Header + 64 bits of Data Datagram
-
- The internet header plus the first 64 bits of the original
- datagram's data. This data is used by the host to match the
- message to the appropriate process. If a higher level protocol
- uses port numbers, they are assumed to be in the first 64 data
- bits of the original datagram's data.
-
- Description
-
- If the gateway processing a datagram finds the time to live field
- is zero it must discard the datagram. The gateway may also notify
- the source host via the time exceeded message.
-
- If a host reassembling a fragmented datagram cannot complete the
- reassembly due to missing fragments within its time limit it
- discards the datagram, and it may send a time exceeded message.
-
-
-
-
-
-
- [Page 5]
-
-
- April 1981
- RFC 777
-
-
-
- Parameter Problem Message
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | Parameter | unused |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Internet Header + 64 bits of Original Data Datagram |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- IP Fields:
-
- Destination Address
-
- The source network and address from the original datagram's data.
-
- ICMP Fields:
-
- Type
-
- 12
-
- Code
-
- 0 = problem with option.
-
- Parameter
-
- If code = 0, IP option type.
-
- Internet Header + 64 bits of Data Datagram
-
- The internet header plus the first 64 bits of the original
- datagram's data. This data is used by the host to match the
- message to the appropriate process. If a higher level protocol
- uses port numbers, they are assumed to be in the first 64 data
- bits of the original datagram's data.
-
- Description
-
- If the gateway or host processing a datagram finds a problem with
- the header parameters such that it cannot complete processing the
- datagram it must discard the datagram. One potential source of
- such a problem is an option that is not implemented, or incorrect
- arguments in an option. The gateway or host may also notify the
- source host via the parameter problem message.
-
-
-
-
-
- [Page 6]
-
-
- April 1981
- RFC 777
-
-
-
- Source Quench Message
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | unused |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Internet Header + 64 bits of Original Data Datagram |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- IP Fields:
-
- Destination Address
-
- The source network and address of the original datagram's data.
-
- ICMP Fields:
-
- Type
-
- 4
-
- Internet Header + 64 bits of Data Datagram
-
- The internet header plus the first 64 bits of the original
- datagram's data. This data is used by the host to match the
- message to the appropriate process. If a higher level protocol
- uses port numbers, they are assumed to be in the first 64 data
- bits of the original datagram's data.
-
- Description
-
- A gateway may discard internet datagrams if it does not have the
- buffer space needed to queue the datagrams for output to the next
- network on the route to the destination network. If a gateway
- discards a datagram, it may send a source quench message to the
- internet source host of the datagram. A destination host may also
- send a source quench message if datagrams arrive too fast to be
- processed. The source quench message is a request to the host to
- cut back the rate at which it is sending traffic to the internet
- destination. The gateway may send a source quench message for
- every message that it discards. On receipt of a source quench
- message, the source host should cut back the rate at which it is
- sending traffic to the specified destination until it no longer
- receives source quench messages from the gateway. The source host
- can then gradually increase the rate at which it sends traffic to
- the destination until it again receives source quench messages.
-
-
-
-
- [Page 7]
-
-
- April 1981
- RFC 777
-
-
-
- The gateway or host may send the source quench message when it
- approaches its capacity limit rather than waiting until the
- capacity is exceeded. This means that the data datagram which
- triggered the source quench message may be delivered.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 8]
-
-
- April 1981
- RFC 777
-
-
-
- Redirect Message
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | Code | unused |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Gateway Internet Address |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Internet Header + 64 bits of Original Data Datagram |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- IP Fields:
-
- Destination Address
-
- The source network and address of the original datagram's data.
-
- ICMP Fields:
-
- Type
-
- 5
-
- Code
-
- 0 = Redirect datagrams for the Network.
-
- 1 = Redirect datagrams for the Host.
-
- 2 = Redirect datagrams for the Type of Service and Network.
-
- 3 = Redirect datagrams for the Type of Service and Host.
-
- Gateway Internet Address
-
- Address of the gateway to which traffic for the network specified
- in the internet destination network field of the original
- datagram's data should be sent.
-
- Internet Header + 64 bits of Data Datagram
-
- The internet header plus the first 64 bits of the original
- datagram's data. This data is used by the host to match the
- message to the appropriate process. If a higher level protocol
- uses port numbers, they are assumed to be in the first 64 data
- bits of the original datagram's data.
-
-
-
-
- [Page 9]
-
-
- April 1981
- RFC 777
-
-
-
- Description
-
- The gateway sends a redirect message to a host in the following
- situation. A gateway, G1, receives an internet datagram from a
- host on a network to which the gateway is attached. The gateway,
- G1, checks its routing table and obtains the address of the next
- gateway, G2, on the route to the datagram's internet destination
- network, X. If G2 and the host identified by the internet source
- address of the datagram are on the same network, a redirect
- message is sent to the host. The redirect message advises the
- host to send its traffic for network X directly to gateway G2 as
- this is a shorter path to the destination. The gateway forwards
- the original datagram's data to its internet destination.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 10]
-
-
- April 1981
- RFC 777
-
-
-
- Echo or Echo Reply Message
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | unused |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Data ...
- +-+-+-+-+-
-
- IP Fields:
-
- Addresses
-
- The address of the source in an echo message will be the
- destination of the echo reply message. To form an echo reply
- message, the source and destination addresses are simply reversed.
-
- IP Fields:
-
- Type
-
- 8 for echo message;
-
- 0 for echo reply message.
-
- Description
-
- The data received in the echo message must be returned in the echo
- reply message.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 11]
-
-
- April 1981
- RFC 777
-
-
-
- Timestamp or Timestamp Reply Message
-
- 0 1 2 3
- 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Type | unused |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Originate Timestamp |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Receive Timestamp |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Transmit Timestamp |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
- IP Fields:
-
- Addresses
-
- The address of the source in a timestamp message will be the
- destination of the timestamp reply message. To form a timestamp
- reply message, the source and destination addresses are simply
- reversed.
-
- IP Fields:
-
- Type
-
- 13 for timestamp message;
-
- 14 for timestamp reply message.
-
- Description
-
- The data received (a timestamp) in the message is returned in the
- reply together with an additional timestamp. The timestamp is 32
- bits of milliseconds since midnight UT. One use of these
- timestamps is described by Mills [5].
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 12]
-
-
- April 1981
- RFC 777
-
-
-
- Summary of Message Types
-
- 0 Echo Reply
-
- 3 Destination Unreachable
-
- 4 Source Quench
-
- 5 Redirect
-
- 8 Echo
-
- 11 Time Exceeded
-
- 12 Parameter Problem
-
- 13 Timestamp
-
- 14 Timestamp Reply
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 13]
-
-
- April 1981
- RFC 777
-
-
-
- References
-
- [1] Postel, J., ed., "DOD Standard Internet Protocol", IEN 128,
- RFC 760, USC/Information Sciences Institute, NTIS ADA079730,
- January 1980. Appears in: Computer Communication Review,
- Special Interest Group on Data Communications, ACM, V.10, N.4,
- October 1980.
-
- [2] Cerf, V., "The Catenet Model for Internetworking," Information
- Processing Techniques Office, Defense Advanced Research
- Projects Agency, IEN 48, July 1978.
-
- [3] Strazisar, V., "Gateway Routing: An Implementation
- Specification", IEN 30, Bolt Beranek and Newman, April 1979.
-
- [4] Strazisar, V., "How to Build a Gateway", IEN 109, Bolt Beranek
- and Newman, August 1979.
-
- [5] Mills, D., "DCNET Internet Clock Service," RFC 778, COMSAT
- Laboratories, April 1981.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- [Page 14]
-